home *** CD-ROM | disk | FTP | other *** search
/ PC World 2000 February / PCWorld_2000-02_cd.bin / Software / Servis / FFE / SOUND.SWG / 0036_D00 Sound Formats.pas < prev    next >
Pascal/Delphi Source File  |  1997-05-11  |  9KB  |  306 lines
  1.                        *** THE D00 FORMAT EXPLAINED ***
  2.                        ***     BY JOACHIM FENKES    ***
  3.  
  4.   This document describes the D00 music format (used by the AdLib
  5. player v4.01
  6. coded by JCH/Vibrants) in more detail than the docs of EdLib (the
  7. respective
  8. tracker, also coded by JCH) do.
  9.  
  10.   This document assumes that you already own EdLib and have some
  11. experience
  12. with it. Also, the availability of the EdLib docs as well as of the
  13. docs for
  14. the player included with EdLib is assumed. You should know some basics
  15. about
  16. AdLib programming and data formats (byte, word etc.) as well as the
  17. EdLib
  18. structures (Instruments, SpFX etc.) and with hexadecimal notation.
  19.  
  20.  
  21.  
  22. CONTENTS
  23. ========
  24.  
  25.   1. The D00 header
  26.   2. The Instrument data
  27.   3. The SpFX data
  28.   4. The arrangement data
  29.   5. The pattern data
  30.   6. Some more infos
  31.   7. Closing words
  32.  
  33.  
  34.  
  35. 1. The D00 header
  36. =================
  37.  
  38.   A description of the D00 header can be found in the player's docs.
  39. So I
  40. won't show it again here. But JCH gives very cryptic names to the
  41. other file
  42. structures, so I'll call them differently:
  43.  
  44.   JCH's names         | My names
  45.  
  46.   TPoin tables        = Arrangment data
  47.   SeqPointer tables   = Sequence data
  48.   Instrument data     = Instrument data
  49.   DataInfo text       = Song description
  50.   Special tables      = SpFX data
  51.  
  52.   Also, I should mention that all the pointers to these tables are
  53. meant relative to the beginning of the D00 file.
  54.  
  55.  
  56. 2. The Instrument data
  57. ======================
  58.  
  59.   The instrument data simply consists of all instruments used in the
  60. song.
  61. Since the number of instruments is stored nowhere inside the file,
  62. loaders
  63. should the start offset of the next structure for determining if they
  64. have
  65. read enough data.
  66.  
  67.   The data for each instrument consists of 16 bytes, which occur in
  68. the
  69. same order as the corresponding bytes in the EdLib Instrument table:
  70.  
  71.     xx xx xx xx xx xx xx xx xx xx xx xx xx xx xx xx
  72.     └────────────┘ └────────────┘ │  │  │  │  │  │
  73.      Carrier data  Modulator data │  │  │  │  └──┴Unused
  74.                                   │  │  │  └Hard restart SR value
  75.                                   │  │  └Hard restart timer
  76.                                   │  └Fine-tune
  77.                                   └AM/FM + Feedback
  78.  
  79.   For the exact meaning of these bytes, read the EdLib manual.
  80.  
  81.   Note that in the Carrier and Modulator data the ADSR parts are not
  82. stored
  83. word-oriented, but byte-oriented. That means, they aren't stored as a
  84. word
  85. whose High byte is the AD part and whose Low byte is the SR part
  86. (although the
  87. display in EdLib creates that assumption). Instead they're simply
  88. stored as
  89. two bytes of which the first one's the AD part and the second one's
  90. the SR
  91. part.
  92.  
  93.  
  94. 3. The SpFX data
  95. ================
  96.  
  97.   The SpFX data ist stored more or less like the Instrument data, but
  98. one
  99. single table entry consists of only 8 bytes arranged like this:
  100.  
  101.     xxxx xx xx xx xx xxxx (note xx's are BYTES and xxxx's are WORDS!)
  102.     │    │  │  │  │  │
  103.     │    │  │  │  │  └Pointer to next SpFX entry
  104.     │    │  │  │  └Duration of SpFX entry in Frames
  105.     │    │  │  └Modulator Level add
  106.     │    │  └New Modulator level
  107.     │    └Note add value
  108.     └Instrument to use
  109.  
  110.   Again, to really understand the meaning of these parts, you should
  111. read the
  112. EdLib docs.
  113.  
  114.  
  115. 4. The Arrangement data
  116. =======================
  117.  
  118.   The arrangement data determines which sequence is to be played on
  119. which
  120. channel at which moment and in which way, if you understand what I
  121. mean :)
  122.  
  123.   It consists of two parts: The Pointer part and the Data part (I
  124. simply call
  125. them that way now :). The Pointer part consists of 16 word pointers
  126. and one
  127. endmark (all endmarks are FFFFh, by the way). Only the first nine
  128. pointers are
  129. used at the moment: one for each one of the nine AdLib channels. Each
  130. one of
  131. these nine pointers points to the part of the Data part which belongs
  132. to its
  133. channel.
  134.  
  135.   The Data part consists, as you'd have guessed before, of nine
  136. independent
  137. arrangement streams. Each one of tese streams has the following
  138. format:
  139.  
  140.   First comes a word telling the speed of that stream. Since this
  141. information
  142. is stored at the beginning of EVERY stream, I assume that every
  143. channel may
  144. have its own unique speed, and EdLib simply doesn't support this.
  145. After that,
  146. the real arrangement data is stored.
  147.  
  148.   This data is organized like this: If a word below 8000h is read,
  149. it's the
  150. number of a sequence to be played. In that case, the saved transpose
  151. data is
  152. used.
  153.  
  154.   But if a word 8XYYh is read, with X and YY being any value, the
  155. transpose data is updated to X and YY (see the EdLib docs for
  156. information on
  157. the meaning of X and YY). I have found out that the first arrangement
  158. entry
  159. for an arrangement stream that contains at least one sequence is
  160. always such
  161. a command to set the internal transpose data. So no default value is
  162. required
  163. to be loaded into the transpose data before playing. And looping the
  164. arrangement stream becomes easier.
  165.  
  166.   If the word FFFFh is read, the arrangement stream has arrived at its
  167. looping
  168. point. The word following the FFFFh is an offset into the arrangement
  169. stream
  170. telling at which position the stream should be restarted.
  171.  
  172.   If the word FFFEh is read, the arrangement stream has reached its
  173. end.
  174. Unlike the Loop command (FFFFh), the stream mustn't get restarted but
  175. halted.
  176. Also, there is no word following the FFFEh command.
  177.  
  178.  
  179. 5. The Sequence data
  180. ====================
  181.  
  182. (I guess you have been waiting for this :)
  183.  
  184.   The Sequence data again consists of a pointer part and a data part.
  185. But this
  186. time these two parts aren't stored in different parts of the file, the
  187. data
  188. part is stored directly after the pointer part. Therefore, a reference
  189. to a
  190. specific pattern should be seen as a reference to a word counted from
  191. the
  192. beginning of the Sequence data. This word (e.g. the first word for
  193. Pattern
  194. 0000h) then points to the offset of the actual sequence data inside
  195. the file.
  196. I hope you got my point...
  197.  
  198.   Then, each sequence is stored as follows:
  199.  
  200.   Read a word. If it's high byte is below 20h, then it's a note. Note
  201. that
  202. RESTs and HOLDs are also counted as notes. In this case, the low byte
  203. can
  204. contain the following values:
  205.  
  206.   00h = REST - The high byte tells the number of rests to insert minus
  207. one!
  208.         e.g. a REST with a high byte of 01h means "Two RESTs"
  209.  
  210.   01h - 7Dh = Note - The value of this note byte tells the amount of
  211.               halfnotes to add to C-0 (e.g. 01h would mean C#0). In
  212. this case,
  213.               the high byte tells the number of HOLDs to insert after
  214. the
  215.               note.
  216.  
  217.   7Fh = HOLD - The high byte tells the number of HOLDs minus one
  218. again!
  219.  
  220.   If the high byte is 20h or above, but below 40h, it's a note again,
  221. but this
  222. time with Tienote switched on. The high word is used as repetition
  223. count
  224. again, but don't forget to substract 20h before evaluating it!!
  225.  
  226.   If the high bzte is 40h or above, it's an effect. In this case, the
  227. complete word can simply be interpreted like any EdLib effect (set
  228. instrument,
  229. set volume etc.). See the EdLib docs for a list of them. The note word
  230. this
  231. effect refers to follows directly after the ceffect word.
  232.  
  233.   If the read word is FFFFh, it indicates the end of that sequence. In
  234. that
  235. case, the next sequence to be played should be determined and loaded
  236. and the
  237. first effect/note of it should be played.
  238.  
  239.  
  240. 6. Some more infos
  241. ==================
  242.  
  243.   The Song description (which is referred to as "DataInfo" by JCH) can
  244. contain simply any kind of data, but it's mostly used as a container
  245. for a
  246. descriptive text. This data is also terminated by an endmark (FFFFh),
  247. even if
  248. it contains no other data.
  249.  
  250.  
  251. 7. Closing words
  252. ================
  253.  
  254.   Okay, this was it. Now you should know as much about the D00 format
  255. as I
  256. know. I hope that you understood my way of describing things and wish
  257. you best
  258. luck with your own tracker/player, maybe both...
  259.  
  260.   I hope that someone finds this text interesting and useful for his
  261. purposes.
  262. I will most probably base my own tracker format (if I code a tracker
  263. some
  264. day :) on a mixture of D00 and TFMX (which is pretty much the same),
  265. maybe
  266. with some bits of XM... In my opinion JCH's sequence system is far
  267. superior to
  268. all of the other pattern-oriented tracker formats I know. Even XM
  269. can't
  270. compete with this system in terms of pattern size. I hope that someone
  271. will
  272. introduce a sequence-based sample tracker system some day (Hope JCH is
  273. reading
  274. this... ;).
  275.  
  276.   Greetings go to:
  277.  
  278.   -Christoph Brzozowski - Greatest Amiga warrior around
  279.  
  280.   -Akintunde Omitowoju - Pushed me to make this description
  281.  
  282.   -Jens Christian Huus alias JCH/Vibrants - Maker of EdLib
  283.  
  284.   -Chris Hülsbeck - Maker of SidPlay on the C64 and TFMX on the Amiga
  285.  
  286.  
  287.   If you wanna contact me, send me an E-Mail:
  288.  
  289.   *** j.fenkes@public.ndh.com ***
  290.  
  291. Sayonara,
  292.   Joachim Fenkes
  293.  
  294. ---snap---8<------
  295.  
  296. Be reading you,
  297.   Joachim
  298.  
  299.  
  300. -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
  301. -=>      Joachim Fenkes     <=-=>  Do *You* Have A  <=-
  302. -=> j.fenkes@public.ndh.com <=-=> Little Green Man? <=-
  303. -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
  304.  
  305.  
  306.